home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / UNSPLIT / text0581.txt < prev    next >
Encoding:
Text File  |  1997-02-06  |  6.5 KB  |  165 lines
  1.  
  2. > Priority decay is briliant, cant believe I missed that :-)
  3.  
  4. :)
  5.  
  6. > Lets say you give a word of priority that decays and reaches zero at the 
  7. > same time as the sample is finished!?!
  8.  
  9. If you want to try this, then that would be even better. :)
  10.  
  11. You could be _really_ insane and use an envelope as the priority! :)))
  12.  
  13. >As for the input, lets have:
  14. * Sample Nr (Word)
  15.  
  16. <cut>
  17.  
  18. This all looks good...
  19.  
  20. > Then you get back a long that is the ID of the sound that later on is used 
  21. > if you want to move the X and Y, or stop the sample.
  22.  
  23. Yes - back-links are going to be useful for modifying any sounds still playing,
  24. but terminating the back-links when a sample stops can be a problem without
  25. having a second back-link in the other direction to null the first link (phew!).
  26.  
  27. But it sounds good!
  28.  
  29. > Currently I have four diferent pitches:
  30. > 12.55KHz, 10.98KHz, 9.41KHz and 7.84KHz
  31.  
  32. So these pitches are hard-wired, rather than dynamic?
  33.  
  34. I take it this is faster (CPU wise) than a variable pitch player..
  35.  
  36. > I did not get the "(around) 9khz" thing, but after trying around in some 
  37.  
  38. Doom plays it's samples at about 9khz, with a random pitch offset of up to
  39. about 3khz - the numbers themselves are just guesses though..
  40.  
  41. > trackers I thinks this will not sound to bad. And dont worry about the 
  42. > speed,   At first I thougth pitch would slow down. But with theese numbers 
  43. > it turned out that it takes less time the more I pitch down from 12.5KHz.
  44.  
  45. Ok..
  46.  
  47. > Nope not such as much code.  The size of the actual code loops depends on 
  48. > how to pitch the sample and 16Bits or 8Bits replay and if it is ambient 
  49.  
  50.  
  51.  
  52. Right. I understand. You have a different loop for each pitch, instead of
  53. one loop with a fractional address generator. Does this save much CPU time?
  54.  
  55. I have never tried fixed loops for this before you see...
  56.  
  57. > sounds. The worst case loop end up at 262Bytes. That is No pitch 16Bit 
  58. > 6.25KHz sample, interleaved and spot sound only.  Only changing to Non Inter 
  59. > leaved will reduse this to 246. Pitches sound decrease even more, not to 
  60. > mention silence!! :-)
  61.  
  62. Right - anything under 256 bytes is ideal.
  63.  
  64. > But the tables will be quite huge!
  65.  
  66. I think we can probably afford this....
  67.  
  68. > 16Bit, DDAdio (3D sound),  will take up more then 250K!!!
  69.  
  70. Fair enough...
  71.  
  72. > Now I calculate the 3D sound in 256 degrees around the player, halving 
  73. > theese steps will halve the size of the table. SubStation uses 16 or 32 
  74. > degrees. So 256 seems to be pointless. But I think I will make it as an 
  75. > aption of: 32, 64, 128 or 256 degrees.  Having 8Bit replay will also halve 
  76.  
  77. Sounds good!
  78.  
  79. > the size. And Only calculating Mono (Distance only) will take the tables 
  80. > away nearly completely!
  81.  
  82. > Therefor I ask if it is possible to allocate memory for theese buffers while 
  83. > playing, or will this make troubles with the cashe routines for the 
  84.  
  85. Allocate while playing? Well - it is possible, but I would need to add semaphores
  86. to prevent clashing between interrupt-based allocations and allocations performed
  87. in the main thread. But it can be done if needed.
  88.  
  89. Do you really need to allocate on-the-fly on an interrupt?
  90.  
  91. > textures???   I would want to be able to not only alloctae memmory whenever 
  92. > I want to. I do also want to change the size of my allocated memory whenever 
  93. > I want to.!  Is this possible???
  94.  
  95. Well, you can allocate when you want, and I can add code to shrink blocks, but
  96. growing blocks will always be a problem. We could have a block lock/unlock option
  97. where blocks can be 'moved' by the manager if unlocked, but if you try this on
  98. and interrupt you will get real problems.
  99.  
  100. So, either drop the allocation on an interrupt, or loose the ability to grow
  101. blocks. Apart from this, everything is ok.
  102.  
  103. > Douglas do also says that some kind of envelope of the sound is wanted. 
  104. > Personaly I cant se why. Dont you fixx those things when you sample the 
  105. > sounds in the first place? I might be wrong but is this realy needed???   It 
  106. > wont take any extra processor power, just need some few more tables. But 
  107. > still are they needed? Do PC doom use envelopes for the sound fx?
  108.  
  109. The envelope is not all that important, but it does let you make more sounds
  110. with the same number of samples. Adds variation (like pitch turbulence).
  111.  
  112. You can leave it out if you want to. It's up to you...
  113.  
  114. > Further more the sound need to be cashed just as the textures. To bad but 
  115. > all sounds dont fit in normal memory. So I would want to reuse the cashe 
  116. > routines for the textures. Or maybe the same routines could be used? This is 
  117. > not urgent right now, but it would be best if I could get  look and 
  118. > description of that piece of code in time :-) (Dont have a clue about how a 
  119. > cashe could be coded in a easy way)
  120.  
  121. Well, the samples should be accessed via the cache, but not on an interrupt.
  122. Otherwise the disk routines will kick in and screw the machine up big time.
  123.  
  124. Cache thrashing must always be via the main thread, and we will need a block
  125. 'locking' flag to ensure the sample remains in memory until it has finished
  126. playing - or a texture might load over it mid-playback. :)
  127.  
  128. > And last but not least:   clock cykles!   I have a clock cykle table for 030 
  129. > in a file called 68030.TXT, this does not make much sence, and dont seem to 
  130. > be very correct as I could see...   So there for I ask for a new timing 
  131. > table. Or someone just could tell me how many cykles the following commands 
  132. > take:
  133.  
  134. Forget about clock cycles - worry instead about bus latency & delayed reads/
  135. writes. A MUCH bigger problem on the Falcon. If you want details, send me a mail.
  136.  
  137. > Hmm, seems like a lot of commands, but some of them are repeated I think. 
  138. > Could someone please just check out the timing for cash hits and non-hits 
  139. > for al of theese and I will be very happy!   And then I would like to know 
  140. > how many clock cykles you aproximatly have each VBL.   If I am to believe 
  141.  
  142. Don't think like that on the Falcon - it's variable by several thousand percent!
  143.  
  144. You have to think almost entirely in terms of bus references, and how well they
  145. overlap with other CPU operations. This is where most of the efficiency is gained.
  146.  
  147. This of course always involves the cache...
  148.  
  149. > Oh, one last thing!   May I use FPU commands???
  150.  
  151. I'd like to avoid FPU, as not everyone has one. We can supply maths
  152. routines if you need them. I think there is a basic SQRT call already
  153. in BM, but a better one can be produced for intensive use.
  154.  
  155. If the DSP is free at the time, we can supply a hardware implementation for you.
  156.  
  157. > I need Square root and arc-sine for the DD Audio calculation...
  158.  
  159. SQRT is no problem. ASin will probably need some tables.
  160.  
  161. Keep up the good work! :)
  162.  
  163. Doug.
  164.  
  165.